home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15978 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 21:06:10 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829011320@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828879781@schonberg> <4k9qhe$65r@solutions.solon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Peter said
  13.  
  14. "How?  No offense meant, but any code which can be affected by this is flat
  15. out broken.  POSIX-style read is to be given a pointer to at least nbytes
  16. of space, for the information read.  Period."
  17.  
  18. That's really confusing, the code in question DID give a buffer large
  19. enough to hold nbytes of data, where nbytes is the number of bytes 
  20. for "the information read". Maybe I don't understand, but reading the
  21. above sentence, it sounds like you would be surprised by the Linux
  22. behavior.
  23.  
  24. Here is the exact case. We declare a buffer of 100 bytes. We read a
  25. 1000 bytes from a file whose total length is 68 bytes. On all systems
  26. that we had experience with other than Linux, this worked fine, the
  27. first 68 bytes of the buffer is filled, and the remaining 32 bytes
  28. is unused. 
  29.  
  30. I am not claiming this is "correct" code in some abstract sense. I
  31. certainly can't tell that it is wrong from the definitions I have
  32. of the read function. What I am claiming is that this worked on
  33. all systems we tried it on, and then failed on Linux. I am not saying
  34. Linux is wrong here, just that its behavior was surprising!
  35.  
  36. The code in question made 100% sure that the data read would never
  37. exceed the buffer size, and I would have been hard pressed to
  38. determine that the code was incorrect. 
  39.  
  40. I am not sure that POSIX is relevant here, almost none of the systems on
  41. which we ran claimed POSIX compliance. Peter, can you post the POSIX
  42. wording on read, I don't have it at hand. Does it in fact make it
  43. clear that the Linux behavior is correct and that the program was
  44. wrong.
  45.  
  46. Let's suppose that the POSIX standard does in fact make it clear that
  47. the Linux behavior is correct. I still think the check is unwise
  48. (note that the check is not against the actual size of the buffer
  49. given, this is of course impossible in C, it is against the end
  50. of the address range of the data area). It's a good example of the
  51. kind of principle I mentioned before. Since almost all systems allow
  52. the program I described above to work correctly, and it is manifestly
  53. safe programming evenif the check is not present, I think it would
  54. be a better choice for Linux not to do this extra check.
  55.  
  56.